Merge RC-3 to master #858
Merge RC-3 to master #858
Conversation
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
…lled. Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
… IlmBase and OpenEXR into one project. Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
…or Imath before including subdirs Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
… to docs/ Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
…m CMake Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Also deprecates Lock Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
Signed-off-by: Owen Thompson <oxt3479@rit.edu>
… IlmBase and OpenEXR into one project. Signed-off-by: Owen Thompson <oxt3479@rit.edu> Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
This is unfortunately intertwined, but is a combination of changes: - fixes from previous changes on this branch - cleaning up cmake setup files after merge of IlmBase and OpenEXR, and splitting Imath - finish removing support for the FORCE_CXX03 flags - removing alternate thread implementations in favor of just c++11 - allowing people to disable thread support entirely Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
This should enable building of internal copy of zlib as necessary, hopefully helping default win32 builds Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
… win32 Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
OpenEXR can now be configured with threads disabled. The classes will still be partially there to maximize portability (but will error / skip appropriately). Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
| * OpenEXR requires CMake version 3.10 or newer | ||
| - NB: CMake 3.12 is required for configuring to build static and | ||
| shared libraries in the same config (object library support) |
There was a problem hiding this comment.
Should we just bump the minimum to 3.12? There are a bunch of other projects in the ecosystem that require at least 3.12, so it's not really like users are making due with 3.10 and we'd be upsetting the apple cart.
|
Oops, some of OIIO's CI tests are failing since this merge, lots of messages about It seems that the OpenEXR CI doesn't specifically test VFX Platform 2021, so we're not noticing if we break it under C++17. |
|
Hmmm... actually... a whole lot of the ASWF docker containers got updated today. It could have been that? I should dig a little more before blaming this PR with certainty. Though it is still true that OpenEXR's CI simply doesn't test VFXPlatform 2021, so it can be hard to tell when things break. |
|
Scratch that. I just watched Borat Subsequent Moviefilm, and clearly my brain is fried. The particular OIIO CI test that is breaking is the "bleeding edge" test using the top of tree master of all the dependencies, and for that one I'm not using any ASWF docker image at all (because none of them have gcc10). And my VFXPlatform 2021 test is passing fine, so OpenEXR is NOT broken against gcc9 + C++17. It's only gcc 10 that's can't build OpenEXR. |
|
I will add VFXPlatform 2021 CI this week. I missed that we had containers for it now. Once OpenEXR is fixed to work on gcc10, I can add a pass for that as well. |
|
Sorry for the panic. I now believe that OpenEXR master is likely fine. The problem I believe is a whole lot of confusion when OIIO's FindOpenEXR picked up an OLD Imath elsewhere on the system. (Why does my package maintain a FindOpenEXR.cmake instead of using the proper exported configs? Mostly because we still support building against Imath/OpenEXR older than when we started exporting config files.) It was that old Imath that still had the old But this fire drill is a good simulation of the kind of confusion that other users (er, and their automated CI builds) are going to encounter when trying OpenEXR 3 for the first time. |
|
lg- I compile with gcc 10.2 at home (run Arch Linux), which works fine? I agree this will be a big shift for people, with a bunch of stuff to update. -k |
|
Yes, please ignore my panicked rambling. The problem was not gcc 10, it was not C++17, and it wasn't even really any changes to the OpenEXR code from your merge. I believe the problems all stem from my own CMake build system expecting OpenEXR 2.x and not being prepared for the new layout, target names, and split between OpenEXR and Imath. Somehow it got itself into a state of including VERY old imath headers elsewhere in the system and mixing them inappropriately with the new openexr libs. Today I'm wrestling with my build system to try to make it work across several different OpenEXR versions (including some so old that they don't have exported config files and targets at all). |
This is a large body of changes, re-organizing in prep for a 3.0 release